Exporting `__rust_alloc_error_handler_should_panic` multiple times
causes ld.gold to balk with: `error: version script assignment of  to
symbol __rust_alloc_error_handler_should_panic failed: symbol not
defined`

Specifically this breaks builds on DragonFly and YoctoProject with
ld.gold.  Builds with ld.bfd should be unaffected.

…anieu"

This reverts commit 90f0b24, reversing
changes made to e173a8e.

The `debug_assert_matches` macro was marked with the `#[macro_export]` attribute,
despite being a declarative macro/macro 2.0, for which the exporting rules are similar
to items. In fact, `#[macro_export]` on a decl macro has no effect on its visibility.

The compiler should emit a more specific error when the `#[macro_export]`
attribute is present on a decl macro, instead of silently ignoring it.

This commit adds the required error message in rustc_passes/messages.ftl,
 as well as a note. A new variant is added to the `errors::MacroExport`
enum, specifically for the case where the attribute is added to a macro
2.0.

This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded).

…ssa-duplicate-export, r=wesleywiser

Avoid exporting __rust_alloc_error_handler_should_panic more than once.

Exporting `__rust_alloc_error_handler_should_panic` multiple times causes `ld.gold` to balk with: `error: version script assignment of  to symbol __rust_alloc_error_handler_should_panic failed: symbol not defined`

Specifically this breaks builds of 1.70.0 and newer on DragonFly and YoctoProject with `ld.gold`.  Builds with `ld.bfd` and `lld` should be unaffected.

http://errors.yoctoproject.org/Errors/Details/708194/

…-macros, r=cjgillot

Warn when #[macro_export] is applied on decl macros

The existing code checks if `#[macro_export]` is being applied to an item other than a macro, and warns in that case, but fails to take into account macros 2.0/decl macros, despite the attribute having no effect on these macros.

This PR adds a special case for decl macros with the aforementioned attribute, so that the warning is a bit more precise. Instead of just saying "this attribute has no effect", hint towards the fact that decl macros get exported and resolved like regular items.
It also removes a `#[macro_export]` attribute which was applied on one of `core`'s decl macros.

- core: Remove #[macro_export] from `debug_assert_matches`
- check_attrs: Warn when #[macro_export] is used on macros 2.0

…nieu

Revert rust-lang#98333 "Re-enable atomic loads and stores for all RISC-V targets"

This reverts rust-lang#98333.

As said in rust-lang#98333 (comment), `forced-atomics` target feature is also needed to enable atomic load/store on these targets (otherwise, libcalls are generated): https://godbolt.org/z/433qeG7vd

However, `forced-atomics` target feature is currently broken (rust-lang#114153), so AFAIK, there is currently no way to enable atomic load/store (via core::intrinsics) on these targets properly.

r? `@Amanieu`

Remove arm crypto target feature

Follow-up to rust-lang/stdarch#1407.

LLVM has moved away from a combined `crypto` feature on both aarch64 and arm, and we did the same on aarch64, but were deferred from doing the same on arm due to compatibility with older LLVM.

As the minimum LLVM version has increased, we can now remove this (unstable) target feature on arm.

r? `@Amanieu`

…e-specific, r=oli-obk

Store the laziness of type aliases in their `DefKind`

Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.

With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:

Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.

As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.

---

This fixes rust-lang#114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](rust-lang#114253 (comment))) as outlined above. Now it does hold.

`@rustbot` label F-lazy_type_alias
r? `@oli-obk`

…-aliases, r=lcnr

Structurally normalize weak and inherent in new solver

It seems pretty obvious to me that we should be normalizing weak and inherent aliases too, since they can always be normalized. This PR still leaves open the question of what to do with opaques, though 💀

**Also**, we need to structurally resolve the target of a coercion, for the UI test to work.

r? `@lcnr`

Rename method in `opt-dist`

This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded). On Linux, it comes from the Dockerfile, on Windows it's downloaded.

Suggested here: rust-lang#114344 (comment)

r? `@lqd`